Reusable IP Addresses in a Dynamic Network Robert B. Hoffman, N3CVL _A_B_S_T_R_A_C_T The topology of amateur packet radio networks changes rapidly due to the frequent addition of new stations, shutting down of old stations, and changing location of others. This paper presents a method for managing IP address assignments within such a network. _1. _B_a_c_k_g_r_o_u_n_d TCP/IP networks require that each host have a unique 32-bit address. These addresses are typically assigned by the network manager who must make sure that no duplicate addresses exist. In the amateur packet radio TCP/IP network, the assignments are done in a hierarchal fashion. The glo- bal coordinator (GC) assigns blocks of addresses to Local Area Network (LAN) coordina- tors who, in turn, assign individual station addresses. The amateur packet radio community is constantly chang- ing due to the adding of new stations, shutting down old stations, changing locations, and the like. In the AX.25 digipeater network, it becomes difficult to maintain an accu- rate map of reliable connec- tion paths. In the TCP/IP network, the job of the LAN coordinator becomes similarly 7777777777777777777777777777777 difficult. When a new station comes on the air in the TCP/IP net- work, its operator must first contact the LAN coordinator to get an address assignment. If the coordinator is unavail- able, the new user may get frustrated and choose a random address which may conflict with previously assigned addresses, causing havoc on the network. In order to ease the adding of new stations to the TCP/IP network, the pro- cess of address assignment must be automated. _2. _A_u_t_o_m_a_t_i_c _A_d_d_r_e_s_s _A_s_s_i_g_n_- _m_e_n_t It can be assumed that the LAN coordinator operates the router for his LAN and that it has knowledge of all LAN address assignments. It therefore has enough informa- tion to be able to assign addresses within the block assigned to it by the GC. 9 December 6, 1988 When a new station comes on the air, it sends a broadcast packet that contains its callsign and a request for a ``permanent'' IP address. The LAN router searches its tables for the station's callsign, and if it is found, it responds with the previously assigned address. If a table entry is not found, the router allocates a new address from its block and assigns it to the requesting station. It also makes an entry in its tables linking the station's callsign with that address. This is similar to the Reverse Address Resolution Protocol [1] that is used in booting diskless workstations. The router then sends a packet to the requesting station inform- ing it of its assignment. The requesting station then records the assignment in its configuration file for subse- quent use. When the current block of addresses is exhausted, a new block would have to be requested from the GC. Currently, the LAN coordinator must make a request to the GC for another block of addresses. As the network develops better connectivity, we may be able to have the LAN router send a special packet to the GC's system to request another block of addresses. The GC would take the next available block and mark it as being assigned to that LAN, and send the information back to the originating LAN router. At the same time, the new block-to-LAN assignment is distributed to all other routers so that they may update their tables. The LAN router may elect to send its request when a few addresses 777777777777777777777777777777777777777777777777777777 are still unassigned in the old block, to allow for delays in response from the GC. The LAN will also have a name server which will prob- ably operate on the same sys- tem as the router. Its func- tion is to accept packets con- taining callsigns and return the associated IP addresses. _3. _A_d_d_r_e_s_s _E_x_p_i_r_a_t_i_o_n The local IP assignments may have an expiration date associated with them so that seldom-seen stations don't tie up IP addresses needlessly. This can be an arbitrarily long time, such as a couple of months. As long as a station remains active at least once during that time period, it retains its assignment and stays in the name servers. If an address expires, it is marked as being available for the next new station. This will lengthen the time before a new address block is needed. _4. _M_o_v_i_n_g _b_e_t_w_e_e_n _L_A_N_s When a station moves from one LAN to another, its IP address would be marked as invalid in the local router, and made to point into a for- warding table that indicates the station's new IP address. This would be maintained for some time to insure that the new IP address has had time to show up on the network's name servers, and so that the old address does not get reas- signed locally until a reason- able time has passed. The rules that govern routing decisions that are made based on a partial IP (subnet) address cannot allow IP addresses to move between 9 December 6, 1988 LANs. This is necessary because one cannot unplug a computer from one organization's network and relocate it to another organization's network and expect to keep the same IP address. With domain style addressing, it wouldn't even have the same hostname. 7777777777 _5. _M_o_b_i_l_e _S_t_a_t_i_o_n_s For mobile packet sta- tions operating away from their home territory, a tem- porary address would be requested from the router in the station's current LAN. The local router then sends a forwarding order to his ``home'' router, cancelling any previous forwarding order. The home router then sends a cancellation order to the pre- vious router so that the pre- vious temporary address may be purged. The temporary address would have a much shorter expiration time than a regular address. This scheme assumes connectivity between all of the LANs on the mobile station's route. _6. _C_o_n_c_l_u_s_i_o_n As the number of stations using TCP/IP grows, it will become increasingly important to respond quickly to changes in the network. For this rea- son, some sort of automated network manangement is neces- sary. The ideas presented here represent a method for managing IP address assign- ments in such a network. _R_e_f_e_r_e_n_c_e_s 1. Finlayson, R., Mann, T., Mogul, J., and Theimer, M., ``Reverse Address Resolution Protocol,'' ARPA RFC 903, June 1984. _A_c_k_n_o_w_l_e_d_g_e_m_e_n_t_s I wish to thank Mike Chepponis, K3MC, and Bdale Garbee, N3EUA, for their assistance and encouragement in the preparation of this paper. 777777777777777777777777777777777777777777777777777777 9 December 6, 1988